Design thinking and agility is a lesson in learning, moving from uncertain to providing confidence
In my first story ‘User Experience is …’ I promised that …
"over the course of a few stories, I’ll try and cover a few of the sciences we draw upon in our art as a creative community to create engaging experiences."
I’ve previously covered developing certainty or confidence within teams by reducing uncertainty and unknowns. This could be through designing with insight or user research but the key is providing certainty to the whole team and having a learning mindset within the team that fosters this partnership.
Design thinking and agility is a lesson in learning, moving from uncertain to providing confidence
Experiences are the end result of the interaction within a product from the users point of view. But this end result, is also made up and influenced by, lots of tiny conversations along the way, between the key partners within the product. This is often described as the ‘product triangle’.
The product triangle, made up of designers, engineers and product
So User Experience is all about the partnerships within the team and also the team’s ability to learn and adapt to insight that is gathered along the way. Whether this is research and design up, front before engineering solutions, or forming assumptions and hypothesis and then building solutions based on those assumptions or focussed around a hypothesise, so the team are able to learn from what’s built and released and able to learn from all of its end users on mass.
Particularly the later approach of building to learn, really requires a strong partnership, so that all of the key partners (design, engineering and product) can recognise and appreciate assumptions but also to formulate hypothesis to test. This requires a good partnership to trust each other when moving into more of the unknown and uncertain areas of product development, but also requires a learning mindset.
Culture and maturity in the team is key to this, to enable these conversations to happened, but also so that the trust can be built within the team.
Cultural Trip Mural by Sam Peet
Culture in its broadest sense is a cultivated behaviour of the whole team including social norms and habits, and both individual and combined team values of the group. It reflects the expected or correct way to think and act, determining what is acceptable, important, and right. It is known that cultural differences pose challenges, as well as opportunities, for the way people interact with each other.
Culture is often looked at from a UX point of view in relation to how users might want to interact with products differently based on their culture or geographic location. However this is also an important consideration in teams and how teams interact in order to bring experiences to life.
Hofstede’s model is the most cited when it comes to investigating the impact of culture.
Ultimately experiences are partnerships in sense-making. The whole team, including the stakeholders need to partner in making sense of a particular problem or challenge, in order to understand how best to solve it from a balanced user and business point of view.
Something that often comes up, when you talk about the roles (not job titles) and partnership for products are questions like:
These are all valid questions, but they all have one problem. They are all coming from an individual perspective, not a team one.
Product Management Venn diagram
If you consider the product triangle or look at it as a Venn diagram, as above. Each of these ‘lenses’ represents the UX/desirability, technology/feasibility and business/viability (either called the Product Management Venn Diagram by Martin Erikson, founder of ‘Mind the Product’, or the ‘three lenses of innovation’, in the design thinking process).
User Experience is … Design Thinking
When empathy was introduced to the Scientific Method, Design Thinking was born and then popularised by the Stamford Design School
If you apply the traditional ‘roles and responsibilities’ approach of placing a resource within a job title to deliver a clearly defined job with individual accountabilities the diagram would be separate circles with large gaps between them. In these gaps knowledge is lost and handoffs and coordination is needed to bridge these gaps, which is less efficient.
If you remove one of these roles, due to holiday or sickness then suddenly there is a massive void of unknown and uncertainty, as one of the ‘jobs’ isn’t being down.
This approach can lead towards tactical solutions, as everyone focuses on their own ‘job’ and not fulfilling the ‘role’ that the team needs. In this case, local-optimisation (i.e. optimising for how many lines of code a developer punches-out or the number of designs a designer produces).
Higher performing product teams focus on the roles that are needed within teams, not resources and job titles. They run marathons, to deliver valuable end-to-end solutions, not sprints to deliver a feature. This lens is more strategic, looking and reaching further out.
In these teams, the lines between the roles start to blur and the diagram looks more like the venn diagram above. But this itself causes confusion as people are more t-shaped, so hybrid roles develop, which can leave people unsure what their role and responsibility is within a team. However the team should clearly define this themselves as part of their ‘team norm’ so they now how to work most effectively and efficiently. Which might be different to other teams.
Teams should be much more than just a group of individuals
The next time you’re thinking about clear and separate lines of accountability or removing any overlap, although this is important, it’s also important to have cohesive teams without boundaries where things can be dropped, go missing, or be forgotten about.
If you talking about accountabilities, don’t think about job titles or people, but think about what roles are needed in the team and which individuals can fulfil those roles. A team member might have more than one role. And a role might not be traditionally part of that person's job title. But it’s all about playing together nicely and helping the team out, not about blaming individuals. Share the burden, help each other out and build on each other’s strengths.
I get it, it often makes total sense from an individual point of view, but is it the best thing for the team overall? Is it the best way that as a team you can serve your customers? Or will it create silos, bottlenecks and potentially dependencies on key people — i.e. only the UX Designer can do that…?
Ultimately the best product teams I’ve worked in, everyone was seen as co-owners of the product, not divorcing parents arguing about who’s gets to keep the cat.
Be a team, not a group of individuals.
And I’ve previously covered a few stories which have a collaboration theme running through them from this one through using design frameworks to guide solutions, all the way though to defining a good product roadmap. Collaboration is key along the way, in particular where we are not the sole owners but have some shared ownership. So next up I’m going to look at when it’s most valuable to collaborate.
Originally written as part of the ‘User Experience is …’ series for UX Collective.